Versions Compared

Old Version 14

changes.mady.by.user Mark H. Wood

Saved on

compared with

New Version 15

changes.mady.by.user Mark Diggory

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Naming is critical in software domain modeling. There are two qualities that you should be looking for in a good name for an entity in your model:
    1. Consistent. Business and developers should always use the same term to define a single concept.
    2. Exact. A name should exactly define the responsibilities of an entity in the domain model.
  2. It should only contain POJOs. The responsibilities assigned to an entity in the domain model should be limited to only those necessary for the software domain.
  3. The domain model shouldn't change because the underlying persistence implementation or the UI or any other layer changes.
  4. Domain Models should not be dependent on the mechanism used to persist them.
    1. SQLException or any other storage level object or response should not be exposed in the domain.
    2. DSpaceObject classes should not be hardcoded to SQL storage calls or directly to DatabaseManager.
  5. A software domain model should be easy to understand for a business domain model expert and it shouldn't have any discrepancy.
  6. There are two reasons why you want to make sure that the code quality of the domain model is top-notch:
    1. The domain model is the foundation of your application. If it is bad, the whole thing can fall apart.
    2. It changes a lot. There are very few areas in your code that are going to change so many times as the domain model.

Architecture: A typical enterprise application architecture consists of the following four conceptual layers:

  • User Interface (Presentation Layer): Responsible for presenting information to the user and interpreting user commands.
  • Application Layer: This layer coordinates the application activity. It doesn't contain any business logic. It does not hold the state of business objects, but it can hold the state of an application task's progress.
  • Domain Layer: This layer contains information about the business domain. The state of business objects is held here. Persistence of the business objects and possibly their state is delegated to the infrastructure layer.
  • Infrastructure Layer: This layer acts as a supporting library for all the other layers. It provides communication between layers, implements persistence for business objects, contains supporting libraries for the user interface layer, etc.

from: http://www.infoq.com/articles/ddd-in-practice

Separating Domain Model from Data Access Services

...